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ABSTRACT 



This thesis chronicles the development of a proof-of-concept, stand-alone, 
Unattended Ground Sensor (UGS) that can be used to sense and process signals 
associated with the motion of large vehicles, troops, or aircraft. The results of this 
signal processing are then transmitted to an Unmanned Aerial Vehicle (UAV). The 
UGS uses acoustic and seismic sensors to provide data to a Digital Signal 
Processing (DSP) computer. Digital signal processing algorithms can be 
independently developed in the C programming language and linked with the 
software developed for this project. 
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I. 



INTRODUCTION 



A. PROBLEM STATEMENT 

Unmanned Aerial Vehicles (UAV) have been under development 
for some time. They have enjoyed a degree of success in 
operational environments. Recently, during Operation Desert 
Storm, it became evident that UAVs could make a significant 
contribution to a warfighting effort. As technology has 
advanced, so too has the number of possible missions that can 
be undertaken by an UAV. Much of the progress in UAV 
technology can be attributed to the development of fast, small 
computers. The Naval Postgraduate School is taking advantage 
of these advances in computer technology and electronic 
miniaturization in an ongoing research project to develop 
several UAV platforms including a Vertical Takeoff and Landing 
(VTOL) UAV called Archytas . As this project nears the 
operational testing phase, more and more missions are being 
envisioned . 

One of the missions being considered is the gathering of 
intelligence from ground detectors. The detectors could also 
take advantage of state-of-the-art miniaturization and 
computer technology. Many small low power digital signal 
processing (DSP) circuit boards are presently on the market. 
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These DSP boards could be used to sample data from sensors, 
process this data, and send only the results to an UAV. 

B. THESIS SCOPE 

This thesis describes the design and construction of an 
inexpensive, compact, self-contained detection device, capable 
of processing and transmitting data. The device was designed 
using current off-the-shelf (COTS) technology hardware. The 
process used to design, build, and test such a device is 
detailed in the following chapters. This device will be 
referred to as Unattended Ground Sensor (UGS) . 

Chapter II is a background chapter describing the 
suitability of an UAV as an intelligence gathering device. 
There is also a discussion in this chapter about the history 
and the future of UGS systems. Chapter III addresses the 
hardware design requirements for the UGS. The fourth chapter 
discusses possible solutions to the design problem. It also 
describes the equipment chosen to fulfill the design 
requirements. Chapter V covers the software design 
objectives. It also describes the programming philosophy and 
solutions used in this design. The concluding remarks and 
recommendations for future development are contained in 
Chapter VI . 

The device described herein is not suitable as the final 
solution to the UGS/UAV combination. It is a technology 
demonstrator and a good test bed for DSP algorithm testing. 
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It is also an excellent platform for UAV/UGS data link 
testing . 
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II . BACKGROUND 



The timely collection and evaluation of battlefield 
intelligence has always been paramount to the success of any 
warfighting scenario. This is still very true in today's 
world. Recent advances in computer and micro-controller 
technologies have breathed new life into some old techniques 
of intelligence gathering. 

The Naval Postgraduate School (NPS) in Monterey, CA has 

been involved in a project that makes use of these advances in 

technology to design Unmanned Aerial Vehicles (UAVs) . The 

potential of the UAV is best stated in the DoD, 1993 Unmanned 

Aerial Vehicles (UAV) Master Plan: 

Unmanned Aerial Vehicles (UAVs) can make significant 
contributions to the warfighting capability of operational 
forces. They greatly improve the quality and timeliness 
of battlefield information while reducing the risk of 
capture or loss of troops, thus allowing more rapid and 
better informed decision making by battlefield commanders. 
They are cost effective and versatile systems. While 
reconnaissance, surveillance, and target acquisition 
(RSTA) are the premier missions of UAVS, they can also 
provide substantial capabilities in electronic warfare 
(EW) , electronic support measures (ESM) , mine detection, 
command and control and special operations mission areas . 
UAVs are a particularly valuable adjunct to the Services' 
aviation communities. They can readily perform a 
multitude of inherently hazardous missions: those in 

contaminated environments, those with extremely long 
flight times and those with unacceptable political risks 
for manned aircraft. Allotting these dirty and dangerous 
missions to UAVs increases the survivability of manned 
aircraft and frees pilots to do missions that require the 
flexibility of the manned system. UAVs are a viable 
alternative as the Services wrestle with the many 
challenges of downsizing the force structure . [Ref . 1] 
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As indicated above the potential tasks for an UAV are nearly 
limitless . 

One enhancement to the RSTA mission mentioned above is to 
use the UAV as a central collection point for intelligence 
transmitted by Unattended Ground Sensors (UGS) . With current 
technology, it is feasible to build a small UGS that can sense 
environmental parameters, detect changes in them, and identify 
the source that caused these changes. All of this can be done 
by a small standalone unit the size of a 12 oz . soda can. 

This chapter will discuss the characteristics unique to an 
UAV that make it ideally suited for intelligence gathering. 
In addition, it will describe the employment and contributions 
of unmanned ground sensors in the Vietnam Conflict. Finally, 
this chapter will discuss the potential of devices similar to 
those used in Vietnam that utilize current technology. 

A. UNMANNED AERIAL VEHICLE (UAV) 

Currently there is considerable interest in the research 
and development of Unmanned Aerial Vehicles (UAVs) . UAVs are 
an excellent compromise between the inexpensive, dumb drone 
and the expensive, but versatile manned aircraft. This 
section describes the UAV's suitability for intelligence 
gathering . 

1. The UAV's Suitability for Intelligence Gathering 

Ideally an intelligence gathering device would have 
the following qualities: 
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• Inexpensive. 

• Expendable. 

• Low probability of being detected by the enemy. 

• Low probability of destruction by enemy. 

• Low failure rate. 

• Mission flexible. 

• Minimum risk to friendly lives . 

A drone is relatively inexpensive when compared to a manned 
aircraft and is often expendable. However, it lacks mission 
flexibility once it has been launched. For example, if the 
drone detected an event worth further investigation during its 
flight, it could not turn around and take a second look. This 
inability to react to real time occurrences is a severe 
limitation in intelligence gathering. On the other hand, a 
manned aircraft is infinitely more flexible, but it also puts 
human life at risk. This means that the situations most worth 
investigating will not be pursued because they are too risky 
to human life. 

Recent advances in technology have made it feasible to 
build a highly survivable, High-Altitude-Long-Endurance (HALE) 
UAV. The issue of survivability can be broken down into two 
separate categories, susceptibility and vulnerability. 
Susceptibility is a measure of the ease with which a system 
can be detected and attacked. Vulnerability is an indication 
of a systems ability to continue its mission once it has been 
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attacked. Both susceptibility and vulnerability must be 
minimized to increase survivability. One method to reduce 
susceptibility is to give the system the ability to defend 
itself. Susceptibility can also be minimized by reducing 
radiated or reflected signatures. The second method decreases 
susceptibility by lowering the probability of detection and 
thereby, maintaining covertness. If the UAV is not detected, 
it will not be fired upon. [Ref. 2] 

The physical characteristics of an UAV will inherently 
minimize its probability of being detected. The advent of 
miniaturized electronics allows for the use of small, powerful 
computers for flight control. Other crucial electronic 
systems, such as the Inertial Navigation System (INS) and the 
Global Positioning Systems (GPS) , have also been reduced in 
size. These developments tend to reduce the airframe size. 
It is obvious that a small UAV is harder to be seen than a 
larger manned aircraft. This is particularly true when the 
small UAV is flying at a high altitude. However, size can 
also be related to the radar cross-section of the UAV. Since 
UAVs are designed to carry smaller payloads than manned 
aircraft, their airframes are smaller. This can translate 
into a smaller engine. The use of nonmetallic, composite 
materials in airframe construction also tends to reduce the 
total weight and by that allow for a smaller engine. By using 
smaller engines (less metal) and nonmetallic materials in the 
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airframe construction, the radar cross-section can be reduced 
to achieve a lower probability of detection . [Ref . 2] 

The use of a small engine in the UAV has the potential 
to reduce the amount of radiated noise and heat to a level 
below that generated by a manned aircraft. The minimization 
of heat and noise generation will also lower the probability 
of UAV detection. [Ref . 2] 

To be an effective real-time intelligence gathering 
tool, the UAV must transmit data to a control station. The 
process of transmitting could compromise the UAV and make it 
more detectable. Fortunately, the use of Spread Spectrum 
communication techniques can reduce the probability of 
detection to acceptable levels. [Ref. 2] 

Vulnerability is the other component of survivability. 
Vulnerability is a measure of the inability of a system to 
continue operating after it has taken a "hit.” One method to 
lower the vulnerability of a system is to make it tougher. 
This can be done by physically protecting vital systems. 
Tough composite materials such as Kevlar or Glass Reinforced 
Plastic (GRP) used in the construction of many UAVs will act 
like Armor protecting vital systems and reducing 
vulnerability . [Ref . 2] 

Cost as well as survivability must be considered in 
the evaluation of an intelligence gathering system. The cost 
of an UAV is usually between that of a drone and a manned 
aircraft. Normally the cost of an UAV is too high to consider 
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it expendable, but low enough to make it a cost-effective 
alternative to a manned aircraft. 

An UAV can be an inexpensive, highly-survivable , 
mission-flexible tool. Additionally, because UAVs have a much 
lower probability of detection than manned aircraft, they are 
less likely to effect the actions of the enemy and thus 
provide better intelligence. All of these factors combine to 
make a HALE UAV the perfect instrioment for gathering 
intelligence . 

B. XJNATTENDED GROUND SENSOR (UGS) 

The Unattended Ground Sensor can play an integral part in 
battlefield intelligence gathering systems. Their utility was 
proven during the Vietnam conflict. [Ref. 3] Even greater use 
can be made of the UGS by incorporating some of today's 
technology. 

1. Uses in the Vietneun Conflict 

Vietnam saw the first use of Unattended Ground Sensors 
using a radio link to a remote monitor [Ref. 4] . In Reference 
5, John Bergin states: 

In 1966 the United States began to build an electronic 
barrier of acoustic, seismic, and radio sensors across the 
northern border of South Vietnam, the panhandle of Laos, 
and the eastern regions of Thailand to detect North 
Vietnamese inf iltration. [Ref . 5] 

Bergin goes on to explain that these sensors were seeded by 

air along the McNamara line. They relayed the detected sounds 

to on-station monitoring aircraft. This information was then 
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used to vector in air strikes against the most promising 
targets. Around 1968 General Westmoreland started using some 
sensors to monitor the perimeters of Marine bases. "They were 
so successful in warning of enemy movements and identifying 
targets for artillery and air support that General 
Westmoreland obtained permission to postpone the completion of 
the McNamara Line to use the sensors in tactical 

operations . " [ Ref . 5 ] 

The reviews of these new state-of-the-art devices were 
nearly all-positive. Assertions were made at Congressional 
ings on the electronic battlefield that these devices were 
!<_ nsible for lowering the American death rate from 12 

percent to 3 percent. In addition, claims were made that a 
battalion with the sensors could monitor twice the area of a 
nonsensor equipped battalion. [Ref . 3] 

Although these sensors were successful, they had some 
serious drawbacks . The first drawback was that they were 
bulky thus making them difficult to deploy and easy to sight. 
This problem was partially addressed by camouflaging them, as 
vegetation. [Ref . 5] 

The second drawback was due to the short battery life 
of the detectors. When the sensor batteries were exhausted or 
near the end of their useful life, patrols had to deployed 
to replace the batteries. These battery replacement patrols 
exposed the troops to unnecessary dangers. 
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A third drawback to the Vietnam era UGS was their 



inability to process raw data. Reference 4 states, "The 
sensor signal must be processed and transmitted over a data 
link, should ideally only transmit when a significant event 
has occurred . . . . " The Unmanned Ground Sensors used in 
Vietnam had to continuously transmit their data to a nearby 
aircraft. This made the sensors vulnerable to detection and 
location by radio direction finding equipment. 

The final drawback stemmed from the fact that manned 
aircraft were used to investigate sensor events. Unlike an 
UAV, these aircraft were large and loud making them counter 
detectable by the simplest of means. This allowed the enemy 
the opportunity to alter their actions and avoid further 
detection. 

Since the Vietnam war, the UGS concept has evolved 
through a series of programs. The Army started a program in 
1972 to develop an all-weather, all-terrain, REmote Monitored 
Sensor System (REMBASS) . This system was intended for 
division level use and incorporated the Platoon-level Early 
Warning System (PEWS). The PEWS became operational in 1980. 
An Improved REMBASS (IREMBASS) system began development in the 
late 1980 's. The system developed here will be very much like 
REMBASS, but with improved signal processing 
capabilities . [Ref . 6] 
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2. Uses in Tomorrow's Conflicts 



All of the applications above have one thing in 
common. They have relied on either a manned aircraft or 
ground station to collect and relay or analyze the data from 
the Unattended Ground Sensors. It is possible, with the 
advances in computing power and data storage, to build an UGS 
that can analyze the sensed data on its own. The UGS would 
then only need to transmit to relay stations or an UAV when 
the detection criterion has been met. If this UGS technology 
were to be coupled with an UAV as the receiver, sensor 
detections could be immediately investigated with a low 
probability of counter detection. The UAV could then transmit 
video and infrared information to a command center for further 
evaluation . 

C. SUMMARY 

Although sensor systems in the past have been successful, 
their performance could be enhanced further with t* ? 
application of modern technology. The UGS/UAV combination has 
great potential for safe, inexpensive, accurate, and stealthy 
intelligence gathering. The application of this system could 
range from the detection of men and vehicles to the detection 
of a ballistic missile launch. 
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III. U6S HARDWARE DESIGN CONSIDERATIONS 



As is true for any system, many design factors must be 
considered to produce the best product possible. Among these 
factors are capabilities, cost, size, weight, and power 
requirements. This proof-of-concept UGS must meet the 
following general design requirements. It should be a highly 
capable, standalone, digital signal processing unit that is 
small enough to fit in a container the size of a 12 oz. soda 
can. It must also be capable of sensing various environmental 
parameters, processing this information, determining if the 
detection criterion is satisfied, and notifying the UAV that 
a detection has occurred. 

The primary goal of this design is to produce a product 
that meets all of the general design requirements. In 
addition, it must be constructed using low cost, commercial 
off-the-shelf (COTS) components. This chapter details the 
design approaches considered in each of the four major 
hardware categories. 

A. SENSING DEVICE REQUIREMENTS 

There were five environmental parameters that were 
considered in developing this device. These parameters were 
chosen for evaluation based on their possible applicability 
and on the environmental sensors that are readily available on 
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the commercial market. The sensors considered for use in 
this design were acoustic, seismic, pressure, magnetic, and 
global position sensing (GPS) devices. This section discusses 
each of these sensors and their applicability to this project. 

1. Acoustic Sensor 

An acoustic sensor can be a simple microphone. This 
type of sensor has several advantages. Microphones are small, 
light weight, and have very low energy consumption. They are 
also readily available. As a sensor it can be used to detect 
an object of interest w-.en that object is loud, but not in 
close physical proximity. Most microphones have a cycloid 
beam pattern. This can be a disadvantage if the orientation 
of the microphone cannot be controlled or if the exact 
location of the target of interest is not known. There are 
some microphones available, however, that have good fidelity 
ranges and a hemispherical beam pattern. It was determined 
that a microphone with a hemispherical beam pattern and a 
frequency response of 50 Hz to 18,000 Hz was necessary for our 
particular application. 

2 . Seismic Sensor 

A seismic sensor can measure very small movements of 
the sensor itself. If the sensor is in solid contact with a 
surface, it will measure the movement of that surface. These 
movements can be detected at frequencies as low as 10 Hz. 
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Seismic sensors can vary greatly in size, weight, and 
cost. One sensor investigated weighed 3.3 pounds and had a 
volume of 25.8 in^ . Another sensor weighed only 1.8 oz and 
had a volume of 0.61 in^ . The cost of these sensors ranged 
from as high as several thousand dollars to as low as a few 
hundred dollars. 

The design requirements specify that the UGS must be 
small; therefore, the seismic sensor should be as small as 
possible. In addition, it was determined that the UGS should 
be sensitive to seismic signals within the frequency range of 
1 to 1000 Hz. 

3 . Pressure Sensor 

Pressure sensors are most useful in applications where 
the pressure transmitting medium is dense or the sensor is 
located very near the pressure source. It was determined that 
neither of these situations would apply for our specific 
application. As a result, no pressure sensor is included in 
the UGS design at this time. 

4 . Magnetic Sensor 

The magnetic sensor can detect disturbances in the 
local magnetic field. These disturbances could be caused by 
the passing of an iron based metal object or a current 
carrying conductor in the proximity of the sensor. A tank, 
for example, would have to pass within approximately one tank 
length of the magnetic sensor to be detected. [Ref. 7] It is 
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anticipated that the UGS will not be close enough to the 
object of interest to make use of a magnetic sensor. 
Consequently, a magnetic sensor is not included in the current 
UGS design. 

5. Global Position Sensor (GPS) 

GPS, if used, could determine the position of the UGS. 
This information could be included in any communication with 
the UAV. The position data could then be used by the UAV to 
pinpoint the detection location or track a disturbed UGS. 
However, for this application it assumed that the UGS's 
position will be known at all times. The use of a GPS sensor 
is, therefore, not required. 

B . TRANSMISSION REQUIREMENTS 

The UGS must be able to periodically transmit an "I am OK" 
signal and aperiodically transmit an "Alarm" signal if the 
processed data indicates that a detection has occurred. 

1. Message Format 

The transmitted message must indicate the identity of 
the UGS and whether an alarm condition exists. In addition, 
it should encode the data to provide some error detection and 
correction capability 

There are two different categories of information 

coding ; 

• Convolutional codes continuously encode long bit streaims. 
This method is best suited for continuous transmissions. 
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• Block codes group the data into blocks and encode these 
blocks as a unit. 

This system will only be transmitting blocks of data; 
therefore, convolutional coding is not necessary. Use of 
block coding is appropriate here. [Ref. 8] 

Several error detection/correction methods use block 
coding. One such method adds a single parity bit to the data 
block. This method will detect a single error, but will not 
provide any error correction capability. Hamming Code is 
another method, which uses 2“-l bits to describe 2'^-1-N data 
bits. It can be used to detect and correct only single bit 
errors: single error detection, single error correction 
(SEDSEC) . Adding another bit to the Hamming scheme above to 
indicate overall parity will allow for the detection of two 
bit errors. This scheme is called double error detection, 
single error correction (DEDSEC) . It requires 2^ bits to 
encode the message and provides for 2”-l-N data bits. 

2 . Transmitter Interface 

The transmitter must be able to communicate with the 
digital signal processor (DSP) board. This can be done via an 
RS-232 serial communication port. Some DSP boards provide 
these ports, while others do not. The UAV project currently 
being developed at the Naval Postgraduate School, Monterey, CA 
is using an intelligent RS-232 controller with an available 
channel for communication with the UGS . 
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Another method of communication between the processor 
and radio is to use the available output ports of the DSP 
board. The types of output on the available DSP boards vary. 
Most of the DSP boards surveyed provide an analog output. 
However, one board investigated also provides a software 
controlled serial output. Either the TTL compatible output or 
the analog output could be used to communicate with a radio. 

3 . Transmitter Requirements 

Besides satisfying the interface requirements, the 
transmitter should have low energy consumption, be battery 
powered, small, light weight, and secure. It also must be 
able to transmit to the UAV at a slant distance up to 30 Km. 
A link budget was calculated to determine the transmitter 
power required for this data link. Below is a list of the 
assumptions made in calculating the link budget: 

1. Transmit from ground to air. 

2. Maximum slant range: R = 30 Km. 

3. Transmission antenna: Monopole with 2.3 dB peak gain. 

4. Pointing loss for transmission antenna: 5 dB 

5. Transmit frequency: 900 MHz (spread spectrum) 

6. Receive antenna: Double skirted ground plane with 6 dB 
gain. 

7. Pointing loss of receiving antenna: 1.0 dB 

8. Moderate weather conditions. 
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As can be seen in Table I below the link budget calculations 
indicate the transmitter must be able to radiate 1.55 watts of 
power for adequate communication. 



Table I UGS/UAV LINK BUDGET 



Transmit Tx 
Tx Antenna Gain (peak) 
Tx pointing loss 

Propagation 

Free Space loss ( ^/47tR) ^ 
Atmospheric absorption 
Precip absorption 

Receive Rx 
Rx Antenna gain 
Rx Pointing 

Noise Power 

Rx Noise (sensitivity=l 
Totals 



Plus 
2.3 dB 


Minus 
5.0 dB 




121.2 dB 
0.0 dB 
0.0 dB 


6 dB 


1.0 dB 


^iv) 


-107.0 dBm 


8.3 dBm 


20.2 dBm 



Difference = -11.9 dbm 

For a +20 dB signal margin, TX power Pt must be 
31.9 dBm or 1.55 watts. 
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C. DIGITAL SIGNAL PROCESSOR (DSP) REQUIREMENTS 

There are many DSP boards being marketed. These boards 
vary in speed, cost, I/O capabilities, signal processing 
capabilities, size, energy consximpt ion, developmental support , 
and technical support. The discussion below describes each of 
these variables and their importance to this design. 

1 . Speed 

There are two aspects of speed to consider for this 
design. The first is processor speed. The processor must be 
able to analyze the sampled data in a timely manner. This is 
necessary to facilitate the transmission of an alarm signal 
within a few seconds of a detection. Also, the faster the 
processor, the more complicated an analysis can be carried 
out . 

The second aspect of DSP board speed is the rate at 
which a signal can be sampled. The board must be capable of 
sampling the input ports at or above the Nyguist rate, a rate 
equal to or greater than twice the highest frequency present 
in the signal applied to the ports. 

2 . Cost 

The DSP board is the most expensive component of this 
design. The cost will be kept low by using COTS DSP boards. 
In addition, the cost can be kept low by purchasing only what 
is needed to fulfill the design requirements. Some allowance 
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can be made for expanded capabilities if the cost remains 
reasonable . 

3. 1/0 Capabilities 

The DSP board must be able to accept at least two 
analog input signals and have one output signal to communicate 
with a transmitter. The output data can be transferred via an 
analog port, a serial port, or a parallel port. 

4. Signal Processing Capabilities 

Digital signal processing is heavily based on 
arithmetic operations. The DSP board should use a 
microprocessor that easily executes arithmetic instructions 
such as multiplication, division, and shift operations. 

The processor should also be able to perform bit 
reversal to aid in the calculation of Fast Fourier Transforms 
(FFT's). In addition it should have onboard memory for 
storing raw and processed data. 

5. Size 

The UGS is to fit in a volume approximately the size 
of a soda can. Consequently, the DSP board must be as small 
as possible. Most DSP boards investigated required less than 
25 in^ . 

6 . Energy Consiimption 

The DSP board is the single largest load of all UGS 
components. To keep the total energy consumption low, the 
power required by the DSP board must be kept to a minimum. 
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This can be achieved by choosing a DSP board that makes use of 
low power CMOS technology. Additionally, some processors also 
have a sleep mode permitting them to conserve energy. 

7 . Developmental Support 

One of the biggest considerations in choosing a DSP 
board is the developmental support that is provided. The DSP 
system purchased should provide for the development, 
debugging, and testing of user written code. This is vital in 
the early stages of product development. However, it is not 
as important once the user has a satisfactory algorithm tested 
and loaded on the DSP board. 

8 . Technical Support 

Most current DSP systems are relatively new, this 
means the accompanying documentation may be incomplete or in 
error. It should be established that the technical support 
department of the DSP board manufacturer is cooperative and 
eager to help resolve any inaccuracies in the documentation or 
technical problems. 

D. POWER SUPPLY REQUIREMENTS 

The UGS is to operate in a stand-alone mode. This 
requires that the DSP board, microphone, and transmitter are 
powered by batteries. The size limitation of the entire unit 
dictates that the battery cannot be too large. This unit, 
however, must continue to operate for prolonged periods of 
time. Both requirements put severe limitations on the energy 



22 



consiamption of the DSP board since it is the largest load on 
the power supply. 

Most currently available DSP boards operate at five volts 
and require 2-3 watts of power. For a three watt device this 
means there is less than 11 hours of operational life for a 12 
volt, 6.5 Amp-hr lead acid battery regulated to five volts. 

To increase the operational lifetime of the system, the 
following alternatives should be investigated: 

• Reduce system loading by replacing the DSP board with a 

low power version. 

• Use efficient, high capacity batteries. 

• Supplement the battery with solar power. 

This proof -of-concept design will not explore these 
alternatives. Instead, this system will be developed using 
both non-rechargeable batteries and sealed, lead-acid 
batteries. It is anticipated that a production system would 
use CMOS ASIC technology, reducing power consiamption by a 
factor of 1000. 

E. SUMMARY 

The design requirements will be met if the UGS is a stand- 
alone unit that uses acoustic and seismic sensors to detect 
and evaluate objects of interest. The evaluation will be 
performed by a digital signal processing board capable of 
receiving at least two input signals. In addition, the DSP 
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board must be able to send information packets indicatir an 
"alarm” or "I am OK condition to a transmitter. The 
transmitter will be a spread spectrum UHF system that receives 
these packets of information and relays them to the UAV. All 
power for the UGS will be provided by batteries. 
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IV. UNATTENDED GROUND SENSOR HARDWARE 



Previous chapters provide a brief background of the UGS 
project and its design considerations. This chapter describes 
the components that are considered for incorporation in this 
project. It will also describe, in detail, the components 
that are included in the final product and the reasons for 
choosing them. Figure 1 shows a block diagram of the UGS 
system as implemented. 




Figure 1 Unattended ground Sensor 
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A. DIGITAL SIGNAL PROCESSOR BOARD 



The DSP board is the most important component of the UGS 
system. As such, the proper selection of a DSP board was 
paramount to the success of this design. Some design 
requirements of Chapter III were given more weight than 
others. The principal factors considered in this design were 
signal processing and I/O capabilities. Since this project 
was unfunded, the cost was another important factor. The next 
level of priority was assigned to the amount of developmental 
and technical support provided by the manufacturers. Finally, 
the lowest priority design considerations were processor speed 
and energy consumption. It was felt that, since this was a 
proof -of -concept device, faster and more energy conservative 
alternatives could be explored later. 

Three DSP systems were considered for use in the UGS. A 
table siammarizing these systems and their attributes can be 
found in Appendix A. The first of these was the Piranha 3111. 
This DSP board is based on a Texas Instruments TMS320C31 
processor made by DSP Research and costs approximately $1500. 
The Piranha 3111 runs at 40 MHz, consumes about two watts of 
power, and communicates with a motherboard via a full duplex 
serial interface. The Piranha Evaluation Board (PEB) is a 
developmental board that can hold one or two Piranha modules . 
By using the PEB the Piranha modules can communicate 
individually with a host PC. They can also communicate with 
each other in a stand-alone mode by supplying the PEB with 
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+5/12 volts. The main drawback of the Piranha 3111 is that it 



has only one analog I/O channel. The Piranha was not chosen 
for development because of its limited technical support and 
limited I/O capabilities. 

The second DSP board considered was the SBC-31 
manufactured by Innovative Integration of Moorpark, 
California. The SBC-31 is a stand-alone processor also based 
on the Texas Instruments TMS320C31, 32 -bit floating-point DSP. 
The board is very versatile with regard to I/O capabilities. 
The SBC-31 supports two fully duplexed RS-232C serial channels 
and a 48-bit digital I/O port. The fully configured SBC-31 
supports analog inputs and outputs. The analog input channels 
are sampled at 200 kHz and have 16 bit resolution. They can 
be configured for 16 single-ended inputs, or eight 
differential inputs; or four differential and eight single 
ended inputs. The SBC-31 has four 16-bit, 200 kHz analog 
output channels. When running at 50 MHz, it is capable of 25 
MIPS sustained performance. [Ref. 9] This board was delivered 
with its development package for $2500.00 and very good 
technical documentation. The cost of the SBC-31 without the 
development package is $1195.00. The biggest drawback for 
this board is its power consumption. The fully configured 
SBC-31 consumes about three watts of power. This high power 
consumption is due, in large part, to its high signal sampling 
rate and A/D conversions. The SBC-31 may be too capable for 
this project. A slower, less capable board might consiame less 



27 



power and still meet the basic design requirements. However, 
further investigation of an UGS system based on the SBC-31 
could prove fruitful. Development of a second UGS system 
based on the SBC-31 is currently planned by NFS. 

The third and final DSP board considered was the EMB-1601A 
manufactured by Wavetron Microsystems of Redwood City, 
California. The EMB-1601A, a block diagram of which is shown 
in Figure 2, is a digital signal processing board based on 
Analog Devices' ADSP2105 chip. This DSP board has two 16-bit 
analog line inputs with RCA connectors, one microphone input, 
and two 16-bit analog line outputs with RCA connectors. It 
can sample the inputs at user determined frequencies that 
range from 5.5125 kHz to 48.00 kHz. Additionally, the EMB- 
1601A can be configured with a ten Mb/s synchronous serial 
port and/or a 9600 bps, RS-232, serial port. [Ref. 10] The 
RS-232 port with an optional development package permits 
communication with a PC. This combination allows the user to 
develop code on a PC and then download that code onto the EMB- 
1601A for testing. Besides the I/O ports mentioned above, the 
EMB-1601A has two parallel I/O pins that can be used for 
signaling or processor control. The EMB-1601A has a lOMHz 
crystal that allows it to execute instructions at a rate of 
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Figure 2 Block Diagram of 
EMB-1601A from [Ref. 10] 
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10 MIPS. [Ref. 11] It can operate in a stand-alone mode with 
a power consumption of about two watts. 

This unit was shipped to NPS with the following options: 

• 8K X 24 zero wait state SRAM. 

• RS-232 based development software and C command library. 

• DSP Assembler, Linker, and Simulator. 

The total cost of this package was $1780.00. Some of the cost 
was' due to the onetime purchase of the development packages. 
The cost of just the DSP board with SRAM was only $590.00. 

There were several errors detected in the technical 
documentation provided by Wavetron Microsystems and Analog 
Devices. However, representatives from both companies were 
very helpful and all noted discrepancies were quickly resolved 
either by phone conversation or electronic mail. The EMB- 
1601A meets all of the design requirements and is suitable for 
use in this UGS system. The board layout for the EMB-1601A is 
shown in Figure 3 . 

B. SENSING DEVICES 

There were two environmental properties considered best 
suited for exploitation in this UGS. This project will make 
use of airborne sound and low frequency ground vibrations by 
sensing acoustic and seismic information. A microphone will 
be used to sense the acoustic information. The specific 
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Figure 3 EMB-1601A Board Layout 



microphone that was chosen is a Pressure Zone Microphone PZM- 
180 made by Crown of Elkhart, Indiana. This microphone has a 
hemispherical polar pattern that allows it to pick up sounds 
around it at sound pressure levels as high as 120 dB. The 
PZM-180 has a frequency response from 50 Hz to 18,000 Hz, with 
an open-circuit sensitivity of 3.2 mV/Pa. This microphone 
costs $190.00, and its characteristics make it ideal for the 
UGS project. 

The seismic information will be sensed by an Oyo Geospace 
HS-J-K3A geophone. This sensor was chosen for its small size 
and weight (0.6 in^ voliame and 1.8 oz. weight) . Two of these 
sensors along with their calibration data and mounting devices 
were donated to this project by the Naval Surface Weapons 
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Center, Silver Springs, Maryland. Figure 4 shows the geophone 
as wired for connection to the DSP board. 




Connector 



Figure 4 HS-J-K3A Geophone with RCA Connector. 

C . TRANSMITTER 

Since the RS-232 port of the DSP board was needed for 
development of this system, it was decided to use the two 
parallel I/O (PIO) pins of the DSP board to send signals to 
the transmitter. The PIO pins are TTL compatible and software 
controlled. The software for this project was developed based 
on the assumption that the transmitter chosen would take one 
TTL input to enable transmission and another TTL input that 
would carry the actual signal. Such a transmitter has not yet 
been identified. However, an interim solution has been found 
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for testing purposes only and can be used until a transmitter 
with the desired properties is identified or built. 

A Lack of funding has prevented purchasing a 
transmitter /receiver pair . Nonetheless, the device identified 
as the temporary solution for use in this project is a 27.145 
MHz, phase modulated, four watt, battery powered transmitter. 
It is made by Linear of Carlsbad, California and comes in 
three different models (MR161T, MR164T and MR168T) . The 
models are differentiated based on the ntimber of inputs they 
can take. For example, model MR164T can encode and transmit 
a unique message to the receiver for each of its four inputs. 
Model MR168T can do the same for its eight inputs. The 
transmitter senses the continuity of its input lines. 
Transmission will occur if a normally open contact is shut or 
a normally shut contact is opened. With simple modifications 
of the software, the PIO pins on the DSP board could be used 
to trigger relays that would be used as the inputs to the 
transmitter. One input could be used to indicate "I AM OK" 
while another input would indicate an "ALARM" condition. 

This transmitter radiates four watts of power, which is 
more than the required 1.55 watts determined in Appendix B. 
It draws less than 20 microamperes in standby and 0.8 amperes 
during its 4-5 second transmission time. The Linear 
transmitters can be powered from an external 12-13.5 VDC power 
supply or nine AAA alkaline batteries. A four-channel 
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transmitter costs about $240.00 and an eight-channel receiver 
costs about $300.00. 

This family of transmitters and receivers meet most of the 
design requirements; however, there are some reasons why it is 
not desired to use these units in the final product. First, 
the low transmission frequency requires a larger antenna than 
that needed for high frequency systems (900 MHz) . Second, the 
receivers used with these transmitters can only handle a 
maximum of eight channels and then only one channel at a time. 
Finally, signals are not transmitted using spread spectrum 
methods making it easy to locate the transmitters using Radio 
Direction Finding (RDF) techniques. 

D. POWER SUPPLY 

The power supply for this device is a 12 volt, 6.5 Amp-hr, 
gel-cell, lead-acid battery made by Power Sonic of Redwood 
City, California. The +12 volt supply is regulated to +5.0 
volts for the DSP board. The microphone is supplied by a 
separate phantom battery source. The transmitter is supplied 
by either the system 12 volt battery or its own internal AAA 
batteries. Figure 5 below illustrates the circuit diagram 
for the +5.0 volt DSP board power supply. 
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Figure 5 +5 volt DSP Power Supply 



E. SUMMARY 

After investigating the alternatives for the four hardware 
categories, the following solutions were chosen for 
implementation : 



• Digital Signal Processing Board: Wavetron Microsystems' 

EMB-1601A. 

• Sensing Devices: Crown PZM-180 microphone, Oyo Geospace 

geophone model HS-J-K3A. 

• Transmitter: Linear's model MR164T four-channel 

transmitter . 

• Power Supply: Alkaline batteries and 12 volt gel-cell 

lead acid battery. 



A system with these components less the transmitter was 
constructed and tested satisfactorily. 
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V. SOFTWARE DESIGN CONSIDERATIONS AND IMPLEMENTATION 



The software phase of this design was a multi-step 
process. The first step was to define the problem. Once the 
problem was defined, a solution algorithm had to be developed. 
The third stage was to implement the algorithm in code and 
debug it. Finally, the code was modified to operate 
independent of the development system and loaded on an EPROM 
for board testing. This chapter describes the entire design 
process, and the resulting problem solution. 

A. PROBLEM DEFINITION 

There are several objectives that must be accomplished in 
this software design. The problem definition is based on 
efficiently satisfying all these objectives. Below is a list 
of the objectives for this design. 

1) The overall software structure should be designed so that 
it meets all of the objectives and is easily expanded by 
linking in additional C language modules. 

2) The code must be loadable onto a boot EPROM for stand- 
alone operation. 

3) The code must cause the DSP board to sample the line or 
microphone inputs at a user determined frequency. 

4 ) The code must process the sampled data to determine if an 
"ALARM" condition exists. 

5) The code must be able to perform hardware self -checks to 
determine operability. 



36 



6) The code must cause the DSP board to transmit device- 
unique signals that periodically indicate "I AM OK" or 
aperiodically indicate that an "ALARM" condition has 
occurred. 

B . SOLUTION ALGORITHM 

There are several programming strategies or philosophies 
that could be used individually or in combination to create a 
program structure that will meet the above objectives. One 
such programming strategy is called the Flow Driven method. 
This method is used when a program needs to step through a 
sequence of instructions with strict control interrupts and 
external inputs. This approach is conceptually simple and is 
good for lockstep type processes. However, it suffers from a 
lack of flexibility. Consequently, this approach is least 
suited for real-time applications. 

A second approach is called the Clock Driven method. This 
method is particularly well suited for maintenance type 
algorithms where a controlling program must call subprograms 
based on the amount of time expired on some clock. However, 
the Clock Driven method may be too constraining if the 
subroutine length is subject to variability or if the number 
of subroutines is small. 

A third approach to program structuring is called the 
Interrupt Driven method. The Interrupt Driven method uses 
real-time occurrences to cause the microprocessor to transfer 
program control to an interrupt handling routine. This method 
is excellent for real-time applications where immediate action 
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is required for a given event. Additionally, these interrupts 
can be nested such that if the processor is servicing one 
interrupt and a higher priority event comes along, the highest 
priority event is always serviced immediately at the expense 
of the lower priority event. When the higher priority event 
servicing is complete, the processor resumes servicing the 
lower priority event. One drawback to using this method is 
that the microprocessor design governs the niomber and type of 
interrupts available. This will limit the program's 
flexibility. 

Figure 6 shows a structure chart for the programming 
algorithm used in this software design. The flow diagrams for 
the individual blocks of this figure can be found in Appendix 
B and the associated source code in Appendix C. As can be 
seen, all three program structuring methods were used. 

The Interrupt Driven method was used to handle 
transferring information to and from the enCOder DECoder 
(CODEC) peripheral. The Transmit Interrupt (SPORTl TX) was 
used during the hardware initialization phase. When the DSP 
board is RESET, an initialization process is begun. This 
process sets up the pertinent registers and parameters 
necessary for the proper operation of the DSP board. At one 
point in the initialization phase, the CODEC is placed in 
Control Mode. Four control words are then sent to the CODEC 
by the microprocessor. These control words specify various 
operating parameters such as sampling rate, data format, and 
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stereo/mono mode. After each control word is sent, a SPORTl 
TX interrupt is generated. The SPORTl TX interrupt handler 
carries out the handshaking routines to ensure the CODEC has 
been initialized. The interrupt handler then places the 
CODEC in Data Mode and disables the SPORTl TX interrupt 



Interrupt Vector Table 




Figure 6 Program Structure Chart 
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after the CODEC initialization is complete. See Appendix B 
for a flow diagram describing the SPORTl TX routine. 

Once the CODEC has been placed in Data Mode, the Receive 
Interrupt (SPORTl RX) is used to receive and store the sampled 
data. This interrupt is also used to send data back to the 
CODEC. The CODEC sends a four-word packet of data to the DSP 
microprocessor at the sampling rate set while in Control Mode. 
When the four-word packet is sent to the microprocessor, a 
SPORTl RX interrupt is generated by the CODEC . The interrupt 
handler will do two things. The first thing the SPORTl RX 
interrupt handler does is, establish conditions for external 
signaling. The microprocessor can generate external signals 
via the CODEC. This is done by properly setting the value of 
the fourth word in a four word packet (cntrl_l) that is sent 
to the CODEC in the last part of this interrupt handler. The 
value of the cntrl_l comes from one of the three message 
arrays ("NORMAL", "I AM OK", and "ALARM”). The message array 
chosen as the source for cntrl_l is based on the value of the 
global variable SIGNAL_FLAG. The variable cntrl_l is assigned 
the value of a message array element. After a certain number 
( txn_divisor ) of SPORTl RX interrupts has occurred, cntrl_l 
will be assigned the next value in message array. When the 
end of the array is reached SIGNAL_FLAG will be checked again 
to determine the appropriate message array. Each entry in a 
message array determines the voltage level of the two parallel 
input /output pins (PIOl, PIOO) on the DSP board. A more 
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detailed explanation of this process can be found in the next 
section . 

The second thing the receive interrupt handler does is 
read the data from the CODEC inputs. The same data is then 
immediately written back to the CODEC for output with one 
exception. It is at this point that a possibly modified 
cntrl_l is sent to the CODEC to set the value of the PIO pins. 
See Appendix B for a flow diagram describing the SPORTl RX 
interrupt handler. 

The Clock Driven method has been used to periodically set 
the SIGNAL_FLAG variable to a value indicating an "I AM OK" 
condition. A timer onboard the microprocessor can be setup to 
generate an interrupt with a period of up to 1.67 seconds. 
However, the frequency of this interrupt must be reduced if 
hardware self-checks are to be conducted hourly. This was 
done by introducing a scaling constant called one_hour. When 
the one_hour variable is set to 2160, significant action will 
only be taken on every 2160*^^ Timer interrupt. This means the 
interrupt handler will take meaningful action about once an 
hour. The meaningful action for this interrupt is to set the 
SIGNAL_FLAG variable to a value indicating an "I AM OK" 
condition. SIGNAL_FLAG will only be set to "I AM OK" if there 
is no preexisting "ALARM" condition. A flow diagram for the 
Timer interrupt handler can be found in Appendix B. Future 
versions of this program could call a hardware checking 
subroutine from this interrupt and use the results of the 
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check to set the SIGNAL_FLAG variable to the appropriate 
value . 

The Flow Driven method has been used to initialize the DSP 
board hardware, initialize the program variables, and call the 
Main.c program. The initialization is accomplished every time 
the EMB-1601A is powered up or reset. The Flow Driven method 
was chosen for the initialization process because the steps of 
this process must be completed sequentially with strict 
control of all interrupts. Once all of the initialization has 
been completed, the Main.c program can be called. Main.c and 
its subroutines are also flow driven, but they must be 
interruptable to allow the sampling and signaling interrupt 
routines to operate. A flow diagram for the initialization 
process can be found in Appendix B. 

C. ALGORITHM ENCODING AND DEBUGGING 

The development tools provided by Analog Devices include: 

• C Compiler and C Preprocessor. 

• ADSP-2100 Family C Runtime Library (floating-point math 
functions. Digital Signal Processing functions, standard 
C operations) . 

• C Source Level Debugging Utility. 

• ADSP-2100 Family simulator. 

• PROM Splitter 

These software tools include a system builder. The System 
Builder creates an architecture file (*.ach) from a user 
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written system file (*.sys) that describes the target system 
being programmed. This architecture file is used by the 
compiler to help determine where variables and code can be 
placed. The system file for the EMB-1601A is called 2105. sys 
and can be found in Appendix C. In addition to the system 
builder, the software tools use an assembler, linker and a 
PROM splitter. The PROM splitter converts the executable code 
into a format that can be loaded onto a PROM. 

The Wavetron Microsystems' development package includes: 

• A boot PROM with the UART driver and user-code download 
routine on it. 

• Object code and source listing for a Fast Fourier 
Transform routine. 

• C++ functions and a library for initializing and 
controlling the EMB-1601A from a C++ program. 

• An Assembler, Linker, and System builder. 

The Wavetron development tools were used exclusively in the 
early phases of the programming process. The first step in 
developing the software portion of this system was to create 
a system file. Once this was done, the next step was to 
assemble, link, and download an example program provided by 
Wavetron. The example program consisted of a batch program 
(*.BAT), several Analog Devices' assembly language modules 
(*.DSP), and a C++ program (*.cpp) . The batch file assembles, 
links, and converts the object code to a format that can be 
downloaded from the PC to the DSP board. The C++ program is 
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used to initialize the DSP board, establish a graphical 
interface, and download the user-code onto the DSP board. 
Once the C++ program downloads the DSP code onto the DSP 
board, it receives data from the DSP board which is used to 
display the frequency spectrum of the input signals on the PC. 
The assembly language modules setup the interrupt tables, 
perform an FFT on two incoming line signals and make the data 
available to the PC for graphing on the PC monitor. Structure 
;harts for these programs are shown Figure 7. The ability to 
graphically display the spectrum of sampled data made these 
routines ideal for monitoring the response of the seismic and 
acoustic sensors. All of the source files for this example 
program can be found on the development software disk provided 
by Wavetron Microsystems. 

After the example program was running successfully , the 
next step was to modify the program so that the voltage levels 
at the PIO pins could be changed. As explained in the 
previous section, this is accomplished by modifying the value 
of the data words that are being sent to the CODEC. By 
changing the value of the PIO bits in cntrl_l, the level of 
the PIO pins can be changed. Figure 8 shows the format of the 
four-word, 48-bit data stream that is sent to and received 
from the CODEC. It should be noted that cntrl_l and cntrl_2 
are subsets of the data stream and are treated as variables in 
the programs. The variable cntrl_l was modified in the 
receive interrupt (SPORTl RX) . This modification was scaled 
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to occur periodically after a set number of interrupts had 
occurred. The scaling was done by setting the variable 
txn_divisor to some desired value. A value of 5000 for 
txn_divisor causes a new value to be sent to the PIO pins at 
a rate of once every two seconds. This slowed rate permits 
visual monitoring of the changing PIO pin values by means of 
an LED display. 

Once the mechanism for changing the PIO pin values was 
proven to work, the next step was to change the PIO levels 
using the Timer interrupt. The timer's initial count, scaling 
value, and reload values are set by writing the appropriate 
values to the memory mapped Timer Registers. By writing to 
these registers, the timer can be setup to generate a periodic 
interrupt as described above. 

The program was then modified to transmit two different 
signals to the PIO pins. The first signal indicates an "I AM 
OK" condition as generated by the Timer interrupt routine. 
The second signal indicates an "ALARM" condition. The alarm 
is periodically generated by setting SIGNAL_FLAG to the 
"ALARM" value at the end of a large infinite loop in the main 
body of the program. The Receive interrupt (SPORTl RX) 
handler periodically checks the SIGNAL_FLAG variable to 
determine the message to be sent. Then the interrupt handler 
sets the cntrl_l variable equal to the first value of the 
appropriate message array and resets the SIGNAL_FLAG variable 
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Figure 7 Structure Charts for the Example Program 
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to indicate a NORMAL condition. After txn_di visor interrupts 
occurred, the cntrl_l variable is set to the next value in the 
message array. When the end of the array has been reached, 
the SPORTl RX handler reexamines the value of the SIGNAL_FLAG 
variable and the process begins again. The bit pattern of the 
messages can be easily modified to indicate the identity of 
different UGSs by changing the message array values in the 
source code. The code can also be easily modified for 
operation with the Linear transmitters described in Chapter 
IV. The source code for this step can be found in file 
TRANSMIT. DSP listing in Appendix C. 

After this algorithm was successfully encoded in Analog 
Devices' Assembly language and debugged, the next step was to 
link a C-language program with it. The C-program was kept 
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simple and was used to set the SIGNAL_FLAG variable to 
indicate an alarm condition when the geophone input exceeded 
a set threshold. This C-code can be found in the listing for 
file CLINK. C in Appendix C. Linking the C-code with the 
assembly language code proved to be quite difficult and 
required considerable technical help from an Analog Devices' 
programming consultant. 

One of the difficulties in linking the progreims stemmed 
from the fact that the ADSP-2100 Family of processors have 
five different memory spaces. Boot memory is one of these 
memory spaces. The Boot Memory (BM) is split into eight pages 
and each page is one-thousand words long for an ADSP-2105 
processor. In addition to BM, there are internal (on chip) 
and external Data Memory (DM) spaces. Program Memory (PM) is 
also split into internal and external sections. The size and 
location of these memory spaces must be specified in the 
system file as mentioned earlier. One of the problems was due 
to the fact that there was no way to dictate where a compiled 
C -program was to be loaded. The G21 compiler provided by 
Analog Devices automatically placed the C-code at address 
0x0000 in internal PM. Since the code on the Wavetron 
Microsystems' PROM also specified that the download routines 
must be placed at address 0x0000 of internal PM, there was a 
conflict in the memory spaces. This conflict prevented 
loading C-linked code onto the DSP board from the PC. It was 



/ 
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determined that there was no solution to get around this 
problem. 

However, there were still two ways to test the code. The 
first method was to run the code on the Analog Devices' system 
simulator. The code tested by this method ran as expected. 
Nevertheless, the only reliable way to test the code with C 
modules linked in is to write the code for stand-alone 
processor operation and load the code onto an EPROM. The 
EPROM can then be installed on the DSP board and the code 
tested. The process for doing this is found in the next 
section . 

D. MODIFICATIONS FOR STAND-ALONE OPERATION 

This section describes the next step in the software 
development. After the code was tested either by simulation 
or downloading it onto the DSP board by means of the Wavetron 
Microsystems' utility programs, it was loaded onto an EPROM 
and tested on the DSP board in a stand-alone mode. 

This process required modifications to the assembly 
language code. The EPROM would replace the Wavetron 
Microsystems' PROM which had setup the interrupt table 
vectors. This meant the stand-alone code must supply its own 
interrupt table settings. It also meant that the modified 
code had to be placed at address 0x0000 in PM. This would 
ensure the interrupt table was in the proper location. With 
these modifications made to the previously developed code, the 
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new code was then compiled and the executable (*.exe) code 
obtained. The PROM Splitter was then invoked to convert the 
executable code into a format suitable for booting. The 
specific format of this bootable version is selectable by the 
proper use of switches in the PROM Splitter (SPL21) command 
line. The bootable code was then downloaded onto a 27C512 
EPROM for DSP board testing. Appendix D contains procedures 
that outline all of the steps that must followed in converting 
a user's C-code to a programmed EPROM. 

An EPROM was programmed at the end of each major stage of 
the software design process to test the code on the DSP board. 
The C- linked program was also loaded onto an EPROM and tested 
satisfactorily. This successful test proved the ability to 
link the user's C-code with the interrupt handlers. 

E. SUMMARY 

The process to develop the code for this project involved 
several steps. The first step was to successfully load the 
example code provided by Wavetron Microsystems onto the DSP 
board. The next major step was to modify this code to prove 
that the PIO pins could be manipulated for transmission. The 
third step used the Timer interrupt and a large infinite loop 
to select the type of signal to be transmitted. The final 
step was to develop C-code that would examine the input data, 
check for an alarm condition, and set the SIGNAL_FLAG 
accordingly. Each of these steps were tested using a software 
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simulator. The code was then verified on the DSP board by 
downloading it to the board via the PC or programming a boot 
EPROM with the code. 

There are only two ways to test code written in the C 
programming language. The first method is to use the software 
simulator provided by Analog Devices. The second method is to 
link the C code with its assembly language header file and 
load this file onto a boot EPROM. Once the boot EPROM is 
installed on the DSP board, the code begins execution at power 
up or when the reset switch is depressed. 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



The Unattended Ground Sensor described in this thesis was 
the best solution that could be provided with the resources 
that were available at the time. The UGS in this design uses 
a digital signal processing board manufactured by Wavetron 
Microsystems to sample acoustic and seismic sensors. The 
acoustic sensor is a microphone made by Crown and has a 
hemispherical beam pattern. The seismic sensor is a small, 
lightweight geophone made by Oyo Geospace. 

The data from these sensors will be processed using DSP 
algorithms that are to be developed. The DSP code developers 
will be able to initiate an ALARM transmission simply by 
setting the global variable SIGNAL_FLAG to a number greater 
than zero. The software written for this project will carry 
out the details of transmitting the ALARM signal. 

A lack of funding prevented obtaining a transmitter for 
incorporation in this design. However, a transmitter was 
identified for temporary use. The transmitter chosen is made 
by Linear and is typically used in burglar alarm systems. The 
drawbacks of this transmitter are that it does not transmit in 
spread spectrum mode and it transmits at too low of a 
frequency. It is recommended that a small, high-frequency. 
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spread spectrum transmitter be developed specifically for use 
in this project. 

The major problem with the UGS designed for this project 
is its high power consumption. The bulk of the power is drawn 
by the DSP board itself. This problem was unavoidable in this 
design due to the requirement to use commercially available 
of-the-shelf technology. There are some DSP systems currently 
being developed that use very low power. One of these systems 
is the Underwater Digital Signal Processor (UDSP) made by 
Mikros Systems Corporation. The UDSP is based on the Allied 
Signals 1750-A microprocessor. It can compute at up to four 
million instructions per second (MIPS) while consuming only 
one watt of power. At five milliwatts it can carry out 
computations at 10,000 operations per second. It is 
recommended that low power devices like this one be 
investigated further for use in future UGS designs. 

This UGS, as designed, is a good platform for developing 
and testing digital signal processing algorithms. Once these 
algorithms have been shown to be effective, the UGS portion of 
the UAV/UGS combination concept will have been proven. 
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APPENDIX A: DSP BOARD SUMMARY 



Table II DIGITAL SIGNAL PROCESSOR COMPARISON CHART 



MFR/MODEL 


CHIP 


COST 


POWER I/O 




DSP 

Research/ Piranha 3111 


TMS320C31 


1500.00 


2 


W 


1-analog I/O 


Innovative 

Integration/SBC~31 


TMS320C31 


1150.00 


3 


w 


2-RS-232 chan 
16-analog in 
4-analog out 
48-bit digital I/O 


Wave tr on 

Microsysteins/EMB-1601 
(with optional meinory) 


ADSP-2105 


590.00 


2 


w 


2 -line in 
2-line out 

1- mic in 

2- PIO pins 
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APPENDIX B: FLOW DIAGRAMS FOR FILE 2105_HDR.DSP 

This Appendix contains the flow diagrams for the file 
2105_HDR . DSP . This file is broken down into the following 
sections ; 

• Initialization Process 

• Transmit Interrupt Handler (SPORTl TX) 

• Receive Interrupt Handler (SPORTl RX) 

• Timer Interrupt Handler 
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Variable & Constant 
declarations 



Initialize interrupt vector 
. table 



Goto reset address and 
begin execution 



Can "C" Hbrary 
initialization routine 



Initialize variables stored 
in DM and external PM 



Initialize ADSP-2105 
addressing registers 



Initialize software reg's 
and place CODEC in 
Control Mode 



Initialization Process 
2105_hdr.dsp 
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Transmit Interrupt (SPORTl TX) 
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Receive Interrupt (SPORTl RX) 

2105_hdr.dsp 



Entiy 
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SPORTl RX page 2 

From previous page 
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Timer Interrupt 

2 1 05_hdr. dsp 



Entry 
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APPENDIX C: PROGRAM SOURCE CODE 



This appendix contains listings of the following files: 



2105. SYS 


Description file for the system builder. 


FREETEST . BAT 


DOS batch file that assembles, links, 
and PROM splits TRANSMIT . DSP . 


PIO_TEST.CPP 


C++ file used to initialize the PC for 
communication with the DSP board and 
send the user code to the DSP board. 


TRANSMIT. DSP 


Assembly language code that tests the 
use of the Timer interrupt to send an "I 
AM OK" signal and a large infinite loop 
to send an "ALARM" signal. 


C- LINK. BAT 


DOS batch file that assembles, links, 
and PROM splits 2015_HDR.DSP and 
CLINK. C. 


CLINK. C 


C file that compares sampled data to a 
threshold value and sets the SIGNAL_FLAG 
to the "ALARM" value if the threshold is 
exceeded. 


2105_HDR.DSP 


Assembly language file that initializes 
the DSP board, contains the interrupt 
handlers, and calls the C program. 



61 



2105. SYS 



{Descliption file for the System Builder specifies the 
amount of data and program memory in the system. The file 
also declares each page of boot memory which will be used.} 



.SYSTEM dsps; 

.ADSP2105; 

.MMAPO; 

.SEG/ROM/BOOT=0 
. SEG/ROM/BOOT=l 
.SEG/ROM/BOOT=2 
. SEG/ROM/BOOT=3 
. SEG/ROM/BOOT=4 
. SEG/ROM/BOOT=5 
. SEG/ROM/BOOT=6 
. SEG/ROM/BOOT=7 



BOOT_0 [1024] 
BOOT_l [1024] 
BOOT_2 [1024] 
BOOT_3 [1024] 
BOOT_4 [1024] 
BOOT_5 [1024] 
BOOT_6 [1024] 
BOOT_7 [1024] 



{system name} 
(specifies processor} 
(boot loading enable} 
(boot page zero} 
(boot page one} 



(boot page seven} 



(internal program memory at absolute address 0x0000, 1024 
words long} 

. SEG/PM/ram/abs=0/code/data int_pm[1024] ; 



(external program memory 4096 words long. External program 
memory and external data memory together cannot exceed 8192 
words } 

. seg/pm/ram/abs=12288/code/data ext_pm[4096] ; 

. seg/dm/ram/abs=0xl000/data mode_select; 



(external data memory 4096 words long.} 
. seg/dm/ram/abs=8192 /data ext_dm[4096] ; 

(internal data memory 512 words long.} 

. seg/dm/ram/abs=14336/data int_dm[512] ; 
. endsys ; 
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FREETEST . BAT 



DOS batch file that assembles, links, and PROM splits 
transmit . dsp . Transmit. dsp tests the software's ability to 
choose and send either an "ALARM" or "I AM OK" signal. 
EMB_BOOT.DSP contains the interrupt table setup and routines 
for downloading code from the PC. See Reference 10 for a 
listing of EMB_BOOT . DSP . 

erase emb_send.dat 
asm21 transmit. dsp -1 
asm21 emb_boot.dsp -1 

ld21 emb_boot transmit -a 2105 -lib -x -g -e 210x 
spl21 21 Ox emb_boot -i -bm 
emb load emb send.dat 
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PIO TEST.CPP 



The following file is a C++ file used to initialize the PC 
for communication with the DSP board and send the user code 
to the DSP board, 

/* Embedded board test */ 

# include " emb_head . hpp " 

#include <stdio.h> 

#include <conio.h> 

#include <dos.h> 

# include <math.h> 

#include <iostream.h> 

void main (void) 

{ 

clrscr ( ) ; 

init_ebl601 ( 1 ) ; /* Initialize EMB1601 on COM2 */ 

load_code ( " emb_send . dat " ) ; /* Load user's DSP code */ 

wait_l ( 5000 ) ; /* Wait 'til code is running */ 

cleanup_com( ) ; /* Reset serial port */ 

} 
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TRANSMIT. DSP 



The following file contains code that uses the Timer 
interrupt to periodically set conditions for sending an "I 
AM OK" signal. It also utilizes an infinite loop in the 
main body to establish conditions for sending an "ALARM" 
signal . 



.MODULE/RAM/ABS=OxBE/BOOT=0 code_dsp; {module name and load 

location) 

•CONST SYS_CTL_REG=0x3FFF; (system control register) 

.CONST mode_sel=0xl000 ; {latched control for Control / Data 

line ) 

q.1d1 0 ID 0 C Is.x's.td.on ★★★★★★★★★★★★★★★★★★★★★★^ 

.VAR/RAM/CIRC CTRLIN [ 4 ]; {circular buffers for data input 

and) 

CTRL0UT[4] ; {output for data mode and 

control mode) 

DATAIN [ 4 ] ; 

DATAOUT_ [ 8 ] ; 

ALARM [16] ; {signal buffers should all be the 
same length) 

IAM0K[16] ; 

NORMAL [16] ; 

signal_flag, LOOP_CNTR; 

FIRST_FLG; {First time thru flag) 

DCB_FLG; {DCB software handshaking flag 
between 1849 & 2105) 

DMODE_FLG; {1849 mode flag i.e. CONTROL or 
DATA modes) 

cntrl_l , cntrl_2 , AR_save, AX0_save, flip, 
flipper, AYl_save; 

AX0H_save, AYlH_save, NUM_SEC, num_samples, 
data_val_; 

.CONST one_hour=17 ; {1:1.67 sec ratio 0 5 kHz sampling, 

2160=1 hour) 

.CONST txn_divisor=2000; {used to slow rate at which bits 

are transmitted, 2000 = Ibit 
every 0.4 sec when sampling at 
5 Khz) 

.CONST threshold=0X00FF; {threshold for incoming signal 

magnitude) 

.CONST min_samples=300; {this is the min number of samples 

to ensure) 

{valid data is available.) 



.VAR/RAM/CIRC 

.VAR /RAM /CIRC 
.VAR /RAM /CIRC 
. var /ram/circ 

. var/ram/circ 
. var/ram/circ 
. var /ram 
.VAR/RAM 
.VAR/RAM 

.VAR/RAM 

.VAR/RAM 

.VAR/RAM 



{ The following statements make these labels visible to 
EMB_BOOT.DSP) 

.ENTRY code_start; 

.ENTRY irq2_intr; 
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•ENTRY irql_intr; 
•ENTRY irqO_intr; 
•ENTRY timer_intr; 

• ENTRY spor t_txm_intr ; 

• ENTRY sport_rec_intr ; 



{================ interrupt vectors ===================== 

code_start: JUMP through; {goto through: at reset} 

irq2_intr: RTI ; {Sample clock interrupt} 



irql_intr: JUMP SETUPCONTROL ; {transmit interrupt} 

irqO_intr: JUMP NEWDATA; {Receive interrupt} 

timer_intr: JUMP HOUR; {Internal timer interrupt} 

sport_txm_intr : RTI; {Serial port transmit interrupt} 

sport_rec_intr : RTI; {Serial port receive interrupt} 



} 



set 



.control : { 

AXl = 0x212C; 
DM(CTRLOUT) = 
AXl = 0x2200; 
DM(CTRL0UT+1) 
AXl = OxCOFO; 

DM(cntrl_l) = 
AXl = OxCOOO; 
DM(cntrl_2) = 
RTS; 



see EMB-1601A users manual for a detailed 
description of the control words} 

{samp freq=44.1 khz, stereo, pcml6, 2104} 
AXl; 

{xtal2 , 64bits/frame, master, serial txn} 
= AXl; 

{ (PIO=ll, etc) Data mode 
parameter defaults} 

AXl; 

{OM, etc} 

AXl; 



reset_f Upper : 

AXO = 0; {reset flipper and assign or step 

buffer} 

DM (flipper) = AXO ; 

AYl = DM (LOOP_CNTR) ; {LOOP_CNTR initialized at reset} 

AR = AYl +1; 

DM(LOOP_CNTR) = AR; 

AXO = AR; 

AYl = %IAMOK; {get length of a message buffer. 

Could have used the length of any message buffer} 
AR = AXO - AYl; 

IF LT JUMP FINISH; 

AXO = 0; 

DM(LOOP_CNTR) = AXO; {reset LOOP_CNTR} 
AX0=DM(signal_flag) ; {get value of signal_flag} 
AR=PASS AXO; 

IF EQ JUMP NORMAL_XMIT; {are conditions normal?} 

IF GT JUMP ALARM_XMIT; {is there an alarm?} 
IAMOK_XMIT: I5=''IAMOK; {set up transmitting lAMOK} 

L5=%IAMOK; 

AX0=0; {return signal_flag to normal after 

transmit conditions set} 
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DM ( signal_f lag) =AXO ; 
JUMP FINISH; 



NORMAL_XMIT: I5 = ''N0RMAL; {establish conditions for) 

L5=%N0RMAL; {no transmission) 

JUMP FINISH; 



ALARM_XMIT: I5=^ALARM; {set up for transmitting an) 

L5=%ALARM; {alarm) 

AX0=0; {return signal_flag to normal 

transmit conditions set) 
DM(signal_flag) =AX0; 



after 



FINISH: 

AXO = DM(I5,M7); 
DM(cntrl_l) = AXO; 
RTS; 



f ill_mssg_buf f er : 



M7=l; {fill buffers for auto transmit) 

{===MSB is the transmit bit (piol) . MSB-1 is the data bit 
(pioO) . ========) 

15 = "^ ALARM; {id=0x0253, alarm=lsb=l) 

L5 = 0; 



DM(I5,M7)=0X00F0 
DM(I5,M7) =0XC0F0 
DM(I5,M7) =0X00F0 
DM(I5,M7) =0XC0F0 
DM(I5,M7) =0X00F0 
DM(I5,M7) =0XC0F0 
DM(I5,M7)=0X00F0 
DM(I5,M7) =0XC0F0 
DM(I5,M7)=0X00F0 
DM(I5,M7) =0XC0F0 
DM(I5,M7) =0X00F0 
DM(I5,M7)=0XC0F0 
DM(I5,M7)=0X00F0 
DM(I5,M7)=0XC0F0 
DM(I5,M7) =0X00F0 
DM(I5,M7) =0XC0F0 



I5=^IAM0K; 

L5 = 0; 

DM(I5,M7)=0X40F0; {PO) 

DM(I5,M7) =0X80F0; {CO) 

DM(I5,M7)=OX40FO; {Cl) 

DM(I5,M7)=0X80F0; {Dl) 

DM(I5,M7)=0X40F0; {C2) 

DM(I5,M7)=0X80F0; {D2) 

DM(I5,M7) =0X40F0; {D3) 



{CO) 

{CD 

{DD 

{C2) 

{D2) 

{D3) 

{D4) 

{C3) 

{D5) 

{D6) 

{D7) 

{D8) 

{D9) 

{DIO) 

{ALARM BIT) 
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DM (15 
DM (15 
DM (15 
DM (15 
DM (15 
DM (15 
DM (15 
DM (15 
DM (15 



,M7) 

,M7) 

,M7) 

,M7) 

,M7) 

,M7) 

,M7) 

,M7) 

,M7) 



=0X80F0 

=0X40F0 

=0X80F0 

=0X40F0 

=0X80F0 

=0X40F0 

=0X80F0 

=0X40F0 

=0X80F0 



{D4} 

{C3} 

{D5} 

{D6} 

{D7} 

{D8} 

{D9} 

{DIO} 

{ALARM BIT} 



I5 = ''NORMAL; 

L5 = 0; 

DM(I5,M7) =OX40F0 
DM(I5,M7) =OX40FO 
DM(I5,M7) =0X40F0 
DM(I5,M7)=0X40F0 
DM(I5,M7) =0X40F0 
DM(I5,M7) =0X40F0 
DM(I5,M7) =0X40F0 
DM(I5,M7) =0X40F0 
DM(I5,M7) =0X40F0 
DM(I5,M7) =0X40F0 
DM(I5,M7)=0X40F0 
DM(I5,M7) =OX40FO 
DM(I5,M7) =OX40FO 
DM(I5,M7) =0X40F0 
DM(I5,M7) =0X40FO 
DM(I5,M7) =0X40F0 
RTS; 



{ensures transmitter is off} 



through : 

IFC=H#003F; {CLEAR ALL PENDING INTERRUPTS} 
IMASK=H#0000; 



{********** initialize variables and registers ★**★★★***★} 

CALL set_control; {sets values of control words} 

AR = %IAM0K-1; {initialize LOOP_CNTR to the length 

of a message array - 1} 

DM ( LOOP_CNTR ) = AR ; 

AXO = txn_divisor; 

DM (flipper) = AXO; 

AXO = 1; 

DM(flip) = AXO; 

AX0=0; 

DM(num_samples ) = AXO; 

DM (data_val_) = AXO ; 

DM(mode_sel) = AXO; 

DM(signal_flag) = AXO; 

AXO = OxFFFF; 
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DM(0x3FFD) = AXO; {load TPERIOD} 

DM(0x 3FFC) = AXO; {load TCOUNT} 

AXO = OxFF; 

DM(0x3FFB) = AXO; {load TSCALE} 

AXO = one_hour; 

DM(NUM_SEC) = AXO; 



{ ====Initialize the transmit buf fers=======================} 

CALL f ill_mssg_buf f er ; 

{====Initilaize the addressing registers of 2105===========} 



L7=%CTRLIN; 

I7=^CTRLIN; 

L6=%CTRLOUT; 

Ml=l; 

M7 = l; 

I6=^CTRLOUT; 

{====Initialize software f lags============================) 

AX0=1; 

DM ( FIRST_FLG ) =AX0 ; 

DM(DCB_FLG)=AX0; 

AX0=0; 

DM(DMODE_FLG) =AX0; { in control mode } 

AY0=DM ( CTRLOUT ) ; 



{====Initialize the DSP's SPORTl Serial port registers=====) 



L2 = 
12 = 



0 ; 

0x3 fef ; 



DM (12, Ml) 
register } 

DM (12, Ml) 
DM (12, Ml) 
DM ( 12 , Ml) 



= OxODFF; 

= 3 83; 

= 849; 



{ linear addressing for register } 
{ point to last DM cntrl reg } 
I6,M7,I7,M7 sportl autobuffer 



{ 



{ rfsdivl } 
{ sclkdivl } 



B#0100000100011111; { sportl control 

register: internal sclk & rfs, normal framing mode 
frame sync not inverted 16-bit word length } 
{====Initialize the DSP's interrupt registers========== 



ICNTL=0xl7; 

IMASK=B#000100 ; {only SPORTl tx interrupt 

enabled initially while in control mode } 
{====EPR0M version does not need the next two lines. 
Sampling freq is set in set_control. NOTE this is also the 
bit rate for transmission===) 



AXO = 0X2104; {set sample freq 5.5125 kHz) 

DM (CTRLOUT) = AXO; 

{ Set bit test mask for DCB bit, used in tx interrupt 

state machine. . . . } 

AY0=DM (CTRLOUT) ; { test mask for DCB bit } 

{..send first control word to switch codec to data mode ...} 
AX0=DM ( 16 , M7 ) ; { send first 16bits of Ctrl word } 



TX1=AX0 ; 
I2=0x3ffe; 



69 



DM(I2,M1) = 0x0000; {No Wait states} 

DM (12, Ml) = OxOclS; {system control reg; sportl 

enabled } 

{ Wait for an interrupt indicating that transmit 

register is ready for new data and that the 2105 has 
received a 16bit word } 



WAITl: AX1=DM(DM0DE_FLG) ; { check dmode flag } 

AR=PASS AXl; 

IF GT JUMP GO_DMODE; { if set, in data mode } 

JUMP WAITl; { else, wait for initialization to 

be completed from tx interrupt routine } 



GO_DMODE : L7 = %DATAIN ; 

I7=^DATAIN; 

' L6=%DATAOUT_; 
I6=^DATA0UT_; 
AX0=DM(I6,M7) ; 
TX1=AX0 ; 

AX0=0X0cl8; 

DM(0X3FFF)=AX0; 

IFC=B#000000111111; 

nop; 

ENA TIMER; 
IMASK=B#000011; { 



{ init 17, L7 for rx autobuffer } 
{ init 16, L6 for tx autobuffer } 

{ send first 16bits of data } 

{ turn on sportl } 

{ clear all pending interrupts } 

{ cycle for IFC latency } 

sportl rx and timer interrupt on } 



main_loop : 

AXO = DM(data_val_) ; 

AR=PASS AXO; 

IF EQ JUMP main_loop; 
secnd_loop : 

AXO = DM(flip); 

AR=PASS AXO; 

IF EQ JUMP NEXT; {get freshest data) 

AX0=DM (DATAOUT_+l ) ; {check right channel against 

threshold} 

AYl = threshold ; 

AR-AX0-AY1; 

IF LT JUMP secnd_lof 
AXO = 1; 

DM(SIGNAL_FLAG) = AXO ; 

JUMP secnd_loop; 

NEXT: 

AX0=DM (DATAOUT_+5) ; {check right channel against 

threshold} 

AY1= threshold; 

AR=AX0-AY1; 

IF LT JUMP secnd_loop; 

AXO = 1; 
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DM ( S IGNAL_FLAG ) = AXO ; 

JUMP secnd_loop; 

{=======Interrupt routines================================= } 

{ Note; AYO contains a bit mask and must NOT be modified 



elsewhere } 

{ } 



SETUPCONTROL : AX0=DM (FIRST_FLG) ; { first time through ? } 



AF=PASS AXO; 

IF NE JUMP DECR_FIRST; { if so, wait until next word 

transmitted} 

AX0=DM ( DCB_FLG ) ; 

AR=PASS AXO; 

IF EQ JUMP DCBFLG_SET; 

AXO=DM(CTRLIN) ; {DCB_FLG has not been set yet) 

AR=AX0 XOR AYO; {check all incoming bits 

including DCB bit) 



IF EQ JUMP SET_DCB; 

RTI; 

DCBFLG_SET: AX0=DM (CTRLIN) ; 

AR=AX0 AND AYO ; 

IF NE JUMP SETDMODE; 

RTI; 

SET_DCB: AX0=0; 

DM(DCB_FLG)=AXO; 

AY0=0x0400; 

AXO=DM(CTRLOUT) ; {DCB was 

DFR=0) 

AR = AXO OR AYO; 
DM(CTRLOUT) =AR; 

RTI; 

DECR_FIRST: AX0=0; 

DM ( F I RST_FLG ) =AX0 ; { 

RTI; 

SETDMODE ; IMASK=0; 

AX0=0X0418; 
DM(0X3FFF)=AX0; 



{set flag if DCB was 0} 

{DCB_FLG was set) 

{only check for DCB bit) 

{if DBC=1 ready for datamode) 



0, prepare to send DCB=1, 



if first time, set flag=0 } 



{disable sportl) 



16 = ''DATAOUT_; 



L6 = 0; 
DM(I6,M7) 

DM(I6,M7) 

DM(I6,M7) 

DM(I6,M7) 



= 0x0000; {reset output & input data 
buffers } 

= 0x0000; {initialize embedded control 
bits } 

= OxCOOO; {out line 1&2 enab, 0 out 
atten, speaker mute) 

= 0x40F0; {PIO, etc) 
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set PIOl 



{To set the digital output pin (open-collector) 
to the desirable value.) 

{ PI0=11 , OVR=0 , IS=0 , LG=0 , MA=15 , RG=0 } 

DM(I6,M7) = 0x0000; (reset output & input data 
buffers) 

DM(I6,M7) = 0x0000; (initialize embedded control 

bits ) 



DM(I6,M7) = OxCOOO; (same as aboveCOOO) 

DM(I6,M7) = 0x40F0; 

(PIO=01,OVR=0, IS=0, LG=0,MA=15,RG=0) 



(To set the digital output pin (open-collector) 
set PIOl to the desirable value.) 

AX0=0X001F; 

DM(0X3FF2) =AX0; { sportl control: external tfs 

external sclk & rfs 
16 bit words ) 

AX0=1; 

dm(mode_sel) =AX0; ( set D/C high ) 

DM (DMODE_FLG) =AX0 ; ( set data mode flag 

high ) 



RTI; 



NEWDATA : 

DIS BIT_REV; 

DM(AR_save) = AR; 

DM(AX0_save) = AXO ; 

DM ( AYl_save ) = AYl ; 

AYl = DM(flipper); 

AXO = txn_divisor; (this number is used as a divisor to 

slow transmission rate) 

AR = AXO - AYl; 

IF EQ CALL reset_f Upper ; (reset flipper and assign or 

incr buffer) 

AYl = DM(flipper); 

AR = AYl + 1; 

DM (flipper) = AR; 

AXO = DM(flip); 

AR = PASS AXO; 

IF NE JUMP second_half; 



AX0=DM(DATAIN) ; 

DM ( DATAOUT_) =AX0 ; 
AX0=DM(DATAIN+1) ; 
DM ( DATAOUT_+ 1 ) =AX0 ; 
AXO = DM(cntrl_2); 
DM ( DATAOUT_+2 ) =AX0 ; 
AXO = DM(cntrl_l) ; 
DM ( DATAOUT_+3 ) =AX0 ; 
AXO = 1; 

JUMP nd_end; 



( get LEFT channel data ) 

{ output LEFT channel data ) 

{ get RIGHT channel data ) 

( output RIGHT channel data ) 



( Toggle "flip") 
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second_half: 

AXO=DM(DATAIN) ; 

DM ( DATA0UT_+4 ) =AXO 
AX0=DM(DATAIN+1) ; 
DM ( DATAOUT_+ 5 ) =AXO 
AXO = DM(cntrl_2); 
DM { DATAOUT_+ 6 ) =AXO 
AXO = DM{cntrl_l); 
DM (DATAOUT_+7 ) =AX0 
AXO = 0; 



{ get LEFT channel data } 

{ output LEFT channel data } 
{ get RIGHT channel data } 

{ output RIGHT channel data } 



{ Toggle "flip"} 



nd_end : 

DM (flip) = AXO; 

AYl=DM(num_samples) ; {the following code sets the 

data_val_ flag} 

AXO=min_samples ; 

AR = AYl-AXO; 

IF GT JUMP clean_up; 

IF EQ JUMP clean_up_l; 

AR = AYl + 1; 

DM(num_samples) = AR; 

JUMP c 1 e an_up ; 
clean_up_l: AXO = 1; 

DM (data_val_) = AXO ; 
clean_up : 

AYl = DM{AYl_save) ; (restore register} 

AXO = DM(AX0_save) ; 

AR = DM(AR_save) ; 

RTI; { return } 

HOUR; 

DM(AX0H_save) = AXO; 

DM (AYlH_save) = AYl; {need to store AR} 

AYl = DM(NUM_SEC) ; 

AXO = DM{signal_flag) ; 

AR = PASS AXO; 

IF GT JUMP hour_end; {prevents overriding an alarm 

condition} 

AR = PASS AYl; 

IF GT JUMP hour_end; {only send every NUM_SEC 

seconds} 

AYl = one_hour ; 

AXO = -1; 

DM (signal_f lag) = AXO; {set flag to indicate lAMOK} 
hour_end : 

AR = AYl - 1; 

DM(NUM_SEC) = AR; 

AXO = DM{AX0H_save) ; 

AYl = DM(AYlH_save) ; {need to restore AR} 

RTI; 

.ENDMOD; 



73 



C- LINK. BAT 



This file is a DOS batch file that assembles, links, and 
PROM splits two input files. One of these files (clink. c) 
is a C-language file that uses an infinite loop to 
continuously monitor sampled input to determine if an ALARM 
condition exists. If an ALARM condition does exist it sets 
SIGNAL_FLAG to the appropriate value. The other file 
(2105_hdr .dsp) is an assembly language file that contains 
the interrupt table, interrupt handlers, and signal array 
initializations. The header file (2105_hdr . dsp) is required 
for a C-program to operate. A detailed description of this 
batch file can be found in Appendix D. 



asm21 2105_hdr.dsp -1 -c -s 

asm21 -1 -c -S -cp -DDMSTACK -DIMAGE=RAM -DANY=RAM 
f rame_lg . dsp 

g21 clink. c frame_lg.obj -a 2105. ach -mreserved=i2 , i3 -v 
-runhdr 2105_hdr.obj -g -save-temps -Wall -o cexample 
spl21 cexample cprom -i -loader -bs 1024 -bb 2048 
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CLINK. C 



This file is a C-language program that uses an infinite loop 
to continuously monitor sampled input to determine if an 
ALARM condition exists. If an ALARM condition does exist it 
sets SIGNAL_FLAG to the appropriate value. 

extern int SIGNAL_FLAG; 
extern int data_val; 
extern int DATAOUT [ ] ; 

void 
main ( ) 

{ 

int rightl , right2 , check_data, sat ; 
sat=l ; 
loopl : 

check_data=data_val ; /*do nothing until the data is 

valid* / 

if ( ! check_data) goto loopl; /*"goto" used because 
optimizer prevents using do-while loop*/ 

loop2 : 

rightl=DATAOUT[l] ; 
right2=DATAOUT[5] ; 

if (rightl>255 || right2>255) SIGNAL_FLAG=1 ; / * threshold 

is 255*/ 

goto loop2; 

} 
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2105_HDR.DSP 



This file is a modified version of transmit . dsp . It is 
loaded at absolute address 0x0000 and is responsible for 
establishing the interrupt table. In addition, for this 
program to link with a C-program, the only registers that 
could be changed permanently are 12 and 13 . For this reason 
the autobuffering registers had to be changed to 12 and 13 . 



•MODULE/RAM/ABS=0x0000 ADSP2 105_Runtime_Header ; {NOTE: this 

must be absOOOO} 

•CONST SYS_CTL_REG=0x3FFF; (system control register} 

.CONST mode_sel=0xl000 ; {latched control for Control / Data 

line } 

^★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★^ 

.VAR/RAM/CIRC CTRLIN[4]; {circular buffers for data input 

and) 

.VAR/RAM/CIRC CTRLOUT[4]; {output for data mode and control 

mode) 

.VAR/RAM/CIRC DATAIN[4]; 

. VAR/RAM/CIRC DATAOUT_ [ 8 ] ; 

.var/ram ALARM[16] ; {signal buffers should be 16 long 

for DEDSEC} 

.var/ram IAMOK[16]; {all buffers must be the same 

length} 

.var/ram NORMAL[16]; 

.var/ram SIGNAL_FLAG_, LOOP_CNTR; 

.VAR/RAM FIRST_FLG; {First time thru flag} 

.VAR/RAM DCB_FLG; {DCB software handshaking flag 

between 1849 & 2105} 

.VAR/? M DMODE_FLG; {1849 mode flag i.e. CONTROL or 

DATA modes} 

.VAR/F- .-I cntrl_l , cntrl_2 , AR_save, AX0_save, flip, 

flipper, AYl_save; 

.VAR/RAM AX0H_save, AYlH_save, ARH_save, NUM_SEC, 

I0_save, buff_addr; 

.VAR/RAM L0_save, num_samples, data_val_; 

.CONST one_hour=17 ; {1:1.67 sec ratio @ 5 kHz sampling, 

2160=1 hour} 

.CONST txn_divisor=2000 ; {used to slow transmission rate, 1 

is minimxim} 

•CONST min_samples=300; {this is the min mam of samples to 

ensure that the available data is 
valid. } 



. ENTRY 



.1 i b_pr og_t erm ; 



. EXTERNAL 
. EXTERNAL 



_lib_setup_everythin-' : 



main 
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.global SIGNAL_FLAG_; 

.global DATAOUT_ ; 

.global data_val_; 

{============= INTERRUPT VECTORS =========================} 

code_start: JUMP through ; nop; nop; nop; 

irq2_intr; RTI; nop; nop; nop; {Sample clock interrupt) 

sport_txm_intr : RTI; nop; nop; nop; (Serial port transmit 

interrupt) 

sport_rec_intr : RTI; nop; nop; nop; (Serial port receive 

interrupt) 

irql_intr; JUMP SETUPCONTROL;nop;nop;nop; 

irqO_intr : JUMP NEWDATA ; nop ; nop ; nop ; (Receive interrupt ) 
timer_intr: JUMP HOUR ; nop ; nop ; nop ; (Internal timer 

interrupt) 



set_control : 

AXl = 0x2104; 
DM(CTRLOUT) = 
AXl = 0x2200; 

• DM(CTRLOUT+l) 
AXl = OxCOFO; 

DM(cntrl_l) = 
AXl = OxCOOO; 
DM(cntrl_2) = 
RTS; 



(samp freq=5.125 khz , stereo, pcml6 , 2104 ) 
AXl; 

(xtal2 , 64bits/frame, master, serial txn) 
= AXl; 

{(PIO=ll, etc) Data mode parameter 
defaults) 

AXl; 

(OM, etc) 

AXl; 



reset_f Upper : 

DM(I0_save) =10; 

DM (L0_save) =L0 ; 

AXO = 0; (reset flipper and assign or step buffer) 

DM (flipper) = AXO; 

AYl = DM(LOOP_CNTR) ; 

AR = AYl +1; 

DM(LOOP_CNTR) = AR; 

AXO = AR; 

AYl = %IAMOK; (could have used any msg buffer) 

AR = AXO - AYl; 

IF LT JUMP FINISHl; 

AXO = 0; 

DM(LOOP_CNTR) = AXO; 

AX0=DM(SIGNAL_FLAG_) ; 

AR=PASS AXO; 

IF EQ JUMP NORMAL_XMIT; 

IF GT JUMP ALARM_XMIT; 

I AMOK_XMI T : 10=^ I AMOK ; 

L0 = 0; 

AX0=0; (return to normal after transmit) 

DM ( SIGNAL_FLAG_) =AX0 ; 
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JUMP FINISH2; 



NORMAL_XMI T : 10 = ^NORMAL ; 

L0 = 0; 

JUMP FINISH2; 

ALARM_XMIT : 10 = ''ALARM ; 

L0 = 0; 

AX0=0; {return to normal after transmit} 

DM ( SIGNAL_FLAG_) =AX0 ; 

JUMP FINISH2; 

FINISHl: 10 = DM(buff_addr) ; 

FINISH2: AXO = DM(I0,M1); 

DM(cntrl_l) = AXO; 

DM (buf f_addr ) = 10; 

10 = DM(l0_save); 

LO = DM(L0_save); 

RTS; 



f ill_mssg_buf f er : {fill buffers for auto transmit} 

{===MSB is the transmit bit (piol) . MSB-1 is the data bit 
(pioO). ========} 



I0 = ''ALARM; 


{id=0x0253, alarm= 


L0 = 0; 




DM(I0,M1)=0X00F0; 


{PO} 


DM(l0,Ml)=0xC0F0; 


{CO} 


DM(I0,M1) =0x00F0; 


{Cl} 


DM(I0,Ml) =0xC0F0; 


{Dl} 


DM (10, Ml) =0x00F0; 


{C2} 


DM(I0,Ml)=0xC0F0; 


{D2} 


DM (10, Ml) =0x00F0; 


{D3} 


DM(I0,Ml)=0xC0F0; 


{D4} 


DM(I0,Ml)=0x00F0; 


{C3} 


DM(I0,Ml)=0xC0F0; 


{D5} 


DM(I0,Ml)=0x00F0; 


{D6} 


DM(I0,Ml)=0xC0F0; 


{D7} 


DM(l0,Ml)=0x00F0; 


{D8} 


DM(I0,Ml)=0xC0F0; 


{D9} 


DM(I0,M1) =0x00F0; 


{DIO} 


DM(I0,Ml) =0xC0F0; 


{ALARM BIT} 


I0 = ''IAMOK; 




L0 = 0; 




DM (10, Ml) =0X40F0; 


{PO} 


DM(I0,Ml)=0x80F0; 


{CO} 


DM(I0,Ml)=0x40F0; 


{Cl} 


DM(IO,Ml)=0x8OFO; 


{Dl} 


DM(IO,Ml)=Ox40FO; 


{C2} 


DM (10, Ml) =0x80F0; 


{D2} 
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DM(I0,M1) =0x40F0 
DM(I0,M1) =0x80F0 
DM(I0,M1) =0x40F0 
DM(I0,M1) =0x80F0 
DM(I0,M1) =0x40F0 
DM(I0,M1) =0x80F0 
DM (10, Ml) =0x4 OFO 
DM(I0,M1) =0x80F0 
DM(I0,M1) =0x40F0 
DM(I0,M1) =0x80F0 

IO=^NORMAL; 

L0 = 0; 

DM(I0,M1) =0x40F0 
DM (10, Ml) =0x4 OFO 
DM (10, Ml) =0x4 OFO 
DM(10,Ml)=0x40F0 
DM(10,M1) =0x40F0 
DM(10,M1) =0x40F0 
DM(10,M1) =0x40F0 
DM(10,M1) =0x40F0 
DM (10, Ml) =0x4 OFO 
DM(10,M1) =0x40F0 
DM(10,M1) =0x40F0 
DM(10,M1) =0x40F0 
DM(10,M1) =0x40F0 
DM(10,M1) =0x40F0 
DM(10,M1) =0x40F0 
DM(10,M1) =0x40F0 
RTS; 



{D3} 

{D4} 

{C3} 

{D5} 

{D6} 

{D7} 

{D8} 

{D9} 

{DIO} 

{ALARM BIT) 



{ensures transmitter is off) 



through : 

CALL 1 ib_setup_every thing ; 

1FC=H#003F; {CLEAR ALL PENDING INTERRUPTS} 
1MASK=H#0000; 

CALL set_control ; 

AXO = %1AM0K - 1; {could have used any buffer for 

length} 

DM ( LOOP_CNTR ) = AXO ; 

AXO = txn_divisor; 

DM (flipper) = AXO ; 

AXO = 1; 

DM (flip) = AXO; 

AX0=0; 

DM (niam_samples ) = AXO; 

DM (data_val_) = AXO; 

DM(mode_sel) = AXO; 

DM(S1GNAL_FLAG_) = AXO ; 

AXO = OxFFFF; 

DM(0x3FFD) = AXO; {load TPERIOD} 
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{load TCOUNT} 



DM(0x3FFC) = AXO; 

AXO = OxFF; 

DM(0x3FFB) = AXO; (load TSCALE} 

AXO = one_hour; 

DM(NUM_SEC) = AXO; 

(====Initialize the transmit buf f ers======================= } 

Ml = l; 

CALL f ill_mssg_buf f er ; 

(====Initilaize the addressing registers of 2105===========} 

L3=%CTRLIN; 

I3 = ''CTRLIN; 

L2=%CTRLOUT; 

I2 = '^CTRL0UT; 

(====Initialize software f lags=============================) 

AX0=1; 

DM ( FIRST_FLG ) =AX0 ; 

' DM(DCB_FLG) =AX0; 

AX0=0; 

DM (DMODE_FLG) =AX0 ; { in control mode } 

AYO =DM ( CTRLOUT ) ; 

{ ====Initialize the DSP's SPORTl Serial port registers=====) 

LO = 0; { linear addressing for register } 

10 = 0x3 fef; { point to last DM cntrl reg } 

DM(I0,M1) = 0x04B7; { I2,M1,I3,M1 sportl autobuffer 

register } 

DM (10, Ml) = 383; { rfsdivl } 

DM (10, Ml) = 849; ( scllcdivl } 

DM(I0,M1) = B#0100000100011111; ( sportl control 

register: internal scllc & rfs, normal framing mode 
frame sync not inverted, 16-bit word length } 

(====Initialize the DSP's interrupt registers============== } 

ICNTL=0xl7; 

IMASK=B#000100 ; (only SPORTl tx interrupt 

enabled initially while in control mode } 

{ Set bit test mas)c for DCB bit, used in tx interrupt 

state machine. . . . } 

AY0=DM (CTRLOUT) ; ( test mask for DCB bit } 

{.send first control word to switch codec to data mode....} 
AX0=DM(I2,M1) ; ( send first 16bits of Ctrl word } 

TX1=AX0; 

I0=0x3f f e; 

L0 = 0; 

DM(I0,M1) = 0x0000; (No Wait states} 

DM (10, Ml) = 0x0cl8; (system control reg: sportl 

enabled } 
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{ Wait for an interrupt indicating that transmit 

register is ready for new data and that the 2105 has 
received a 16bit word } 

WAITl: AX1=DM(DM0DE_FLG) ; { check dmode flag } 

AR=PASS AXl; 

IF GT JUMP GO_DMODE; { if set, in data mode } 

JUMP WAITl; { else, wait for initialization to 

be completed from tx interrupt routine } 



GO_DMODE : 

L3=%DATAIN; { 

I3=^DATAIN; 

L2=%DATA0UT_; { 

I2=^DATA0UT_; 
AX0=DM(I2,M1) ; 

TX1=AX0 ; 

AX0=0x0cl8; 
DM(0x3FFF)=AX0; 
IFC=B#000 000111111; 
nop; 



init 13, L3 for rx autobuffer } 
init 12, L2 for tx autobuffer } 
{ send first 16bits of data ) 

{ turn on sportl ) 
clear all pending interrupts } 
{ cycle for IFC latency } 



ENA TIMER; 

IMASK=B#000011 ; { sportl rx and timer interrupt on } 



CALL main_; 

1 ib_pr og_term : 



{Begin C program} 
JUMP lib_prog_term; 



(=======Interrupt routines=================================) 

{ Note: AYO contains a bit mask and must NOT be modified 



elsewhere } 

{ } 



SETUPCONTROL ; AX0=DM (FIRST_FLG) ; { first time through ? } 



AF=PASS AXO; 

IF NE JUMP DECR_FIRST; 

AX0=DM(DCB_FLG) ; 
AR=PASS AXO; 

IF EQ JUMP DCBFLG_SET; 
AX0=DM(CTRLIN) ; 

AR=AX0 XOR AYO; 
including DCB bit) 

IF EQ JUMP SET_DCB; 

RTI; 

DCBFLG_SET: AXO = DM (CTRL IN) ; 

AR=AX0 AND AYO ; 

IF NE JUMP SETDMODE; 
RTI; 

SET_DCB: AX0=0; 

DM ( DCB_FLG ) =AX0 ; 
AY0=0x0400; 



{ if so, wait until next word 
transmitted) 



(DCB_FLG has not been set yet) 
(check all incoming bits 

(set flag if DCB was 0} 

(DCB_FLG was set) 

(only check for DCB bit) 

(if DBC=1 ready for datamode) 
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AXO=DM (CTRLOUT) ; {DCB was 0, prepare to send DCB=1, 

DFR=0} 

AR = AXO OR AYO; 

DM (CTRLOUT) =AR; 

RTI; 



DECR_FIRST: AX0=0; 

DM(FIRST_FLG) =AX0; { if first time, set flag=0 } 

RTI; 

SETDMODE : IMASK= 0 ; 

AX0=0x0418; {disable sportl} 

DM(0x3FFF) =AX0; 



12 = ^DATAOUT_; 

L2 = 0; 

DM(I2,M1) = 0x0000; (reset output & input 

data buffers} 

DM(I2,M1) = 0x0000; (initialize embedded 

control bits) 

DM(I2,M1) = OxCOOO; (out line 1&2 enab, 0 out 

atten, speaker mute} 
DM(I2,M1) = 0x40F0; (PIO, etc} 

(To set the digital output pin (open-collector) set PIOl to 
the desirable value.} 



{ PIO=ll , OVR=0 , IS=0 , LG=0 , MA=15 , RG=0 } 
DM(I2,M1) = 0x0000; (reset output & input 

data buffers} 

DM(I2,M1) = 0x0000; (initialize embedded 

control bits} 

DM(I2,M1) = OxCOOO; (same as aboveCOOO} 

DM (12, Ml) = 0x40F0; 

( PIO=01 , OVR=0 , IS=0 , LG=0 , MA=15 , RG=0 } 

(To set the digital output pin (open-collector ) set PIOl to 
the desirable value.} 

AX0=0x001F; 

DM ( 0x3FF2 ) =AX0 ; { sportl control: external tfs, 

external sclk & rfs 16 bit words } 



AX0=1; 

dm(mode_sel) =AX0; { set D/C high } 

DM ( DMODE_FLG ) =AX0 ; { set data mode flag high } 

RTI; 



NEWDATA : 

DIS BIT_REV; 
DM(AR_save) = AR; 
DM(AX0_save) = AXO; 
DM(AYl_save) = AYl ; 
AYl = DM(flipper); 
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AXO = txn_divisor ; {this number is used as a divisor 

to slow transmission rate} 

AR = AXO - AYl; 

IF EQ CALL reset_f lipper ; (reset flipper and assign or 

incr buffer) 

AYl = DM(flipper); 

AR = AYl + 1; 

DM (flipper) = AR; 

AXO = DM(flip); 

AR = PASS AXO; 

IF NE JUMP second_half; 



AXO=DM(DATAIN) ; 

DM (DATAOUT_) =AX0 ; 
AXO =DM ( DATAIN+ 1 ) ; 

DM (DATAOUT_+l ) =AX0 ; 
AXO = DM(cntrl_2); 
DM ( DATAOUT_+2 ) =AX0 ; 
AXO = DM(cntrl_l) ; 
DM ( DATAOUT_+3 ) =AX0 ; 
AXO = 1; 

JUMP nd_end; 



( get LEFT channel data } 

{ output LEFT channel data } 

( get RIGHT channel data } 

( output RIGHT channel data } 



( Toggle "flip") 



second_half : 

AXO=DM(DATAIN) ; 

DM ( DATAOUT_+4 ) =AX0 ; 
AX0=DM(DATAIN+1) ; 
DM ( DATAOUT_+5 ) =AX0 ; 
AXO = DM(cntrl_2); 
DM (DATAOUT_+6 ) =AX0 ; 
AXO = DM(cntrl_l); 
DM (DATAOUT_+7 ) =AX0 ; 
AXO = 0; 



( get LEFT channel data } 

( output LEFT channel data } 
( get RIGHT channel data } 

( output RIGHT channel data } 



( Toggle "flip") 



nd_end : 

DM (flip) = AXO; 

AY1=DM (num_samples ) ; (the following code sets the 

data_val_ flag) 

AXO=min_samples ; 

AR = AYl -AXO ; 

IF GT JUMP clean_up; 

IF EQ JUMP clean_up_l; 

AR = AYl + 1; 

DM (num_samples) = AR; 

JUMP c 1 e an_up ; 
clean_up_l: AXO = 1; 

DM (data_val_) = AXO; 
clean_up : 

AYl = DM(AYl_save) ; (restore registers) 

AXO = DM(AX0_save) ; 

AR = DM(AR_save); 
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RTI; 



{ return } 



HOUR: 

DM(AXOH_save) = AXO ; 

DM(AYlH_save) = AYl; 

DM(ARH_save) = AR; 

AYl = DM(NUM_SEC); 

AXO = DM(SIGNAL_FLAG_) ; 

AR = PASS AXO; 

IF GT JUMP hour_end; {prevents overriding an alarm 
condition} 

AR = PASS AYl; 

IF GT JUMP hour_end; (only send every NUM_SEC 

seconds} 

AYl = one_hour; 

AXO = -1; 

DM ( SIGNAL_FLAG_) = AXO; (set flag to indicate lAMOK} 
hour_end: 

AR = AYl - 1; 

DM ( NUM_SEC ) = AR ; 

AXO = DM(AXOH_save) ; 

AYl = DM(AYlH_save) ; 

AR = DM(ARH_save) ; 

RTI ; 

. ENDMOD; 
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APPENDIX D: PROCEDURES FOR COMPILING NEW CODE AND EPROM 

LOADING 

Compiling New Code: 

Below is a listing of the DOS batch file C-LINK.BAT (also 
listed in Appendix C) . This file causes several actions to 
occur . 

asm21 2105_hdr.dsp -1 -c -s 

asm21 -1 -c -s -cp -DDMSTACK -DIMAGE=RAM -DANY=RAM 
f rame_lg . dsp 

g21 clink. c f rame_lg . obj -a 2105. ach -mreserved=i2 , i3 -v 
-runhdr 2105_hdr.obj -g -save-temps -Wall -o cexample 
spl21 cexample cprom -i -loader -bs 2048 -bb 2048 

The first line assembles the header file 2105_hdr.dsp. 
This file contains the interrupt table settings, interrupt 
handlers and initialization routines. 

The second line was included to correct a bug in the 
software sent by Analog Devices. The bug was in the file 
f rame_lg . dsp . This program is used by C-routines when calling 
and returning from subroutines . It is only supposed to push 
and pop non-dag (non-Data Address Generator) registers 
(M,I,and L registers) on a stack. The bug came from the fact 
that the routine would push and pop registers 12 and 13 . 
These registers are supposed to be reserved for the user and 
are the only registers available for autobuffering. Without 
the modification to frame_lg .dsp, a return from some routine 
could possibly load an erroneous value into 12 and 13 . This 
would cause unpredictable results in operations using 
autobuffering. The file frame_lg.dsp can be corrected by 
removing all operations that affect 12 and 13. 

The third command line compiles clink. c and links it with 
frame_lg.obj and 2105_hdr . obj . If more than one file C-file 
is to be compiled and linked, simply replace clink. c with 
Q^files_all. Where files_all is an ASCII file containing the 
C-files to be compiled (one path\f ilename per line) . 

The last line is the PROM splitter command line. The PROM 
slitter converts executable into a foinnat that can be 
downloaded onto an PROM or EPROM. The -i switch converts the 
executable code into Intel hex format. The -loader switch 
automatically splits large code up between the boot pages as 
specified by the -bs and the -bb switches. The -bs switch 
specifies the boot page size in while the -bb switch specifies 
the boot boundaries. The splitter will put the output in a 
file named cprom. bnm. 
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EPROM Loading 

The following procedure describes the process for 
programming an EPROM at the Naval Postgraduate School. 

1. Erase one D27C512 EPROM for 20-30 minutes under an UV 
light. The digital lab manager in Bullard has an UV light 
available for this purpose. 

2. Ensure the cprom.bnm file is loaded on a 3 60KB 5.25" 
floppy disk and insert disk containing *.bnm in drive a:\. 

3 . While the EPROM is being erased, goto the PC in the 
digital lab that has the Modular Circuit Technology's (MCT) 
PROM burner installed and type met at the C:> prompt. 

4. At the main menu select the Utility option. 

5. Pick opt. 0 to convert the *.bnm file to binary format. 

6. Enter the full path name of the input file when prompted 
(i.e. a:\cprom.bnm). 

7. Enter the output file name when prompted. 

8. Enter I (Intel) for source file hex format. 

9. Choose the Programmer option from the main menu. 

10. Choose option 1 at the next menu to program an EPROM. 

11. At the MFR prompt enter 08 for Intel chip. 

12. Enter 12 for the type of chip (D27C521) 

13 . At the next menu choose option 2 to load the binary file 
into the buffer. 

14. At filename prompt, enter the full path name of the 
binary file (i.e. a:\cprom.bin). 

15. Set load address = 0. 

16. Place an erased EPROM in the MCT unit as illustrated on 
top of the unit. 

17. Select option A. This will blank check, program, and 
verify the EPROM. 

18. If the erased EPROM is locked into the MCT ZIP socket, 
enter Y at the "Ready to Start?" prompt. 
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19. When the verification is complete enter <CR> at the 
prompt and remove the EPROM. 

20. With power secured to the DSP board, insert the newly 
programmed EPROM into Boot Memory socket. Ensure chip 
orientation is correct. Pin #1 should be closest to jumpers 
J1 and J2 . 

21. Program execution will begin at power-up or when reset 
switch SI is pressed. 
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